Data archiving is not a new concept as organizations use it to manage the database volume to manage SAP footprints. As S/4HANA architecture, where the database is already a columnar database for a robust and fast performance of reporting/transactions, why are we discussing data archiving now? There can still be organizations with a very high data footprint and looking for archiving old data, especially for clients who converted their old SAP system to S/4HANA and thus may carry the legacy data if not archived before moving to S/4HANA.
There are many changes in the data archiving concept and the impact on the process etc. in S/4HANA compared to the legacy way to doing data archiving and this article will focus more on such aspects as listed below:
(1) Is DATA Archiving needed in S/4HANA?
Mainly data archiving is performed for two reasons:
i. Performance improvement
S/4HANA Is already a columnar database structure, and thus performance for the query's performance is relatively high if proper filters and selections are defined. Therefore, the performance issues need investigating at the process/design level more than the database level in S/4HANA architecture.
Secondly, we can also utilize the data aging concept, which moves the old/ not frequently accessed data to the database's cold storage area, thus improving the reports' throughput time.
ii. Data footprint reduction to save on hardware cost
The data footprint in S/4HANA is already relatively reduced with the integrated data architecture, e.g., in Finance, there are now universal journal entry tables wiping out the legacy redundant tables of totals and indexes, etc.
Data archiving should be considered in S/4HANA only if not manageable by other data aging options, process design, etc.
(2) Change of archiving objects and the chain of sequence:
Focusing on Finance data, there is now a lot of interdependency of the archiving objects summarized below, where key points:
First, the sub-ledger related documents need archiving before running the financial document archiving.
CO_ITEM and CO_TOTAL were old objects and no longer supported in S/4HANA and mainly replaced by CO_TRANS archiving object
CO_TRANS does not archive all CO documents. The documents linked to other short-term master data, like internal order, are covered by other objects. Orders related documents get archived with object CO_ORDER, similarly asset master related documents get archived with AM_ASSET.
Some objects, like CO_ORDER, archive transaction data, and related master data. So, if you plan to archive transactions for orders related postings, order master data archiving should also be considered.
During FI_DOCUMNT archiving, the BKPG, BSEG, etc. will get deleted earlier, but ACDOCA will change status (field BSTAT) in not actual removal of the line. For AP/AR, the data archived also gets stored in backup tables.
And then you need to run the Totals run the data in ACDOCA is neutralized for archived documents, so that it shows only the picture for the unarchived data when reporting based on ACDOCA.
(1) So, when the data gets archived from ACDOCA?
As you may have noticed already, in the chain mentioned in (2) above, the data is still lying there in ACDOCA, but with status (field BSTAT) updated for archived documents. Even the records may increase with FI totals archiving, which creates a balancing line for comprehensive reporting.
So how to get ACDOCA size reduced, as that will even be bulkier than classical concern table BSEG, due to the ledger wise data.
To get ACDOCA reduced after FI total archiving, you also need to execute the “Compression Run” process, which deletes the ACDOCA lines for archived documents. This compression run performs aggregation at balance carry forward level granularity, thus not changing the balances. The compression run involves the execution of below transactions:
• FINS_ARC_ANALYZE (analyzing tool)
• FINS_ARC (production run)
• FINS_ARC_MONITOR (monitoring tool)
(2) Is database reorganization still helping to improve the database size in S/4HANA?
In S/4HANA, reorganization unnecessary as the database automatically takes care of the delta merge due to the columnar database storage.
(3) Performance of the archiving process
Compared to ECC, archiving as such runs quite fast in the S/4HANA system, and thus you may not need such restrictions (like limiting the archiving run company code-wise, country-wise, etc.) when performing archiving in the S/4HANA system.
(4) What happens for post-processing steps in FI document archiving?
In legacy (ECC) SAP environment, during the posting of a financial accounting document, the actual document data is stored in tables BKPF and BSEG. Additionally, these tables' data is written redundantly to secondary index tables BSIS, BSAS, BSAD, BSAK, BSIP, and BSIM. Note that the data from table BSIM deletes with the actual document. This redundancy aims to provide faster access to data in some applications, such as the line item report function. Retention of the secondary indexes guarantees a line item display that archives for account numbers to be found.
However, for the S/4HANA environment, secondary index tables are no more exist as those are just a view on the universal journal tables. However, during the delete job, SAP stored that information in the index table (which picks that information from ACDOCA), and thus it needs to execute as a post-processing step.
(5) Impact on the reporting etc. especially in the S/4HANA environment:
Talking about the unique impacts considering S/4HANA architecture, please notice below:
Fiori Apps accessing S/4HANA data using oDATA service does not pick the archived data as standard oDATA services are not designed to select the archived data.
Analysis for office (A4O) reports also does not show the archived data from S/4HANA automatically.
The reports built in the ACDOCA table need to ensure that those consider the document status and the total balancing lines created during the archival process.
If you are using central finance architecture connecting one to more source system(s) to the central finance system, standard reconciliation reports do not consider the archived data.
(6) Make sure to have the non-production run for data archiving in a production-like data:
S/4HANA is not a very old production, so not all scenarios might not have been considered in the standard design for data archiving. So, it is always a best practice to run the data archiving on a production-like data to check the impact on the various process flows, reporting, etc. I have seen many recent OSS fixes on standard objects, like handling ledger-specific postings, reporting data structure population for Archival Information System, etc. You may need to apply some notes on top of the standard out-of-the-box solution for data archiving.
I hope this gives you a view on some crucial areas for data archiving on top of the things you may have already seen in legacy systems in the past.